This invention is a methodology for configuring complementary data processes to: operate in concert; have reduced applications and operating system software, perform concurrent cooperative multi-processing multi-tasking operations, have over 1000% improvement in performance and have outstanding implementation cost.
The following references were a part of the literature study undertaken during the 1992 and 1993 time frame during the invention period.
1. Structured Rapid Prototyping, John L. Connell and Linda Shafer, 1989 Prentice-Hall, Englewood Cliffs, N.J.
2. Improving Software Quality, Lowell Jay Aurthur, 1993 John Wiley & Sons, New York, N.Y.
3. Object-Oriented Design with Applications, Grady Booch, 1991 Benjamin/Cummings Publishing, Redwood City, Calif.
4. Decline and Fall of the American Programmer, Edward Yourdom, 1992 Prentice-Hall, Englewood Falls, N.J.
5. Pentium Processor Users Manual, Vol 3, Architecture and Programmers Manual, Intel Literature, PO Box 7641, Mt. Prospect, Ill.
6. Alpha Architecture Reference Manual, Richard L. Sites, Digital Press, Maynard, Mass.
7. Inside SCO UNIX, Steve Glines, Peter S. Spicer, Benjamin A. Hunsberger, Karen Lynn White, 1992 New Rider Publishing, Carmel, Ind. 46032.
8. Guide Real-Time Programming, POSIX 1003.4, Digital Equipment Corp., Maynard, Mass.
9. Sable Systems Overview, Digital Equipment Corp., Maynard, Mass.
10. SEI Documents, Software Engineering Institute, Annotated Listing of Documents, 1993 Carnegie Mellon University, Pittsburgh, Pa. 15213
11. IBM Dictionary of Computing, ISBN 0-07-113383-6, 10th Edition (August 1993) McGraw-Hill, New York, N.Y.
Multi-Tasking and Multi-Processing are tasks that cost software developers millions of hours in development time. The major problem is using the sequential processing Operating system and invoking interrupts while attempting to resolve multiple process requirements. Current system throughput is effected by the Overhead required by the Operating system of the platform, &gt;50%. The time delays are due to interrupts, context switching, exceptions and wait states. Schedulers and Priority Allocations also use interrupts and context switching for accomplishment of their tasks. Concurrency and Cooperative Processing normally uses clock sharing, wait states or multi-processors to achieve their objectives. Current system procedures and operational procedures must be revised through a planned methodology that accomplishes the same objective with simpler steps and in much less time.
The number of processors used in a system requires special Software modifications for Multiple parallel processing or Symmetric processing. Multiple parallel processing does not work well when the number of processors is less than 10. However, Symmetric processing does not work well when the number of processors is more than 10 due to operating system problems and allocations of memory. The Multiple parallel processing divides one large task into N tasks. Symmetric processing divides a number of tasks into equal work load tasks.
This causes multi-processing problems for the Operating system. Multi-tasking is very difficult for the Multiple parallel processing configuration but can be segregated to one task per processor in the symmetric configuration. The processes must perform multi-tasking of all types with simpler methodology. Concurrent operations are normally handled by sharing clock cycles, 1/N, or assigning one processor for each task. Cooperative processing normally uses Wait-States or FIFO modes of operations. They normally add to the Overhead of the Operating system. Single, MMP or Symmetric configurations do not have Complementary processing. Complementary Processing (CP) capabilities need to be added to the system. Complementary Processing will allow Multi-Processing with much lower Software Overhead, far simpler operations, reduced design costs and Software design time.
Real Time Kernels are normally used for Real Time or Embedded Systems. These kernels still use Interrupts and Context Switching. The Real Time Kernel can also be preempted by the System Operating system. The operating performance of the Real Time Kernel is about the same as the System Operating system but it restricts performance to tasks in the kernel. The overall operating time is about the same for the Real Time Kernel as for the System Operating system. There are no outside interferences for the Real Time Kernel except in the case of Preemption. The Real Time Kernel was analyzed, but could not be used due to the system constraints of its operating procedures. The Real Time operating system needs to be designed in a manner that will reduce its operating time by 50 or 60 percent (no Interrupts or Context Switching). Data drivers for the Applications Programs (AP) are also scheduled by the Operating system. These data drivers are for the disk system, interim buffers, input/output for the interim buffers and the AP, display generators and other associated AP's. These data drivers are separte drivers and are handled sequentially. These steps are lengthy and should be reduced to simple memory transfers, without interim buffers and done concurrently. Allocation of memory is normally made at compile time, by Operating system allocations and other dedicated memory tasks. Applications programs normally use memory allocations from disk swapping and other memory requirements from virtual memory. Virtual memory is also used for storage of processed data from the applications programs. The cost of memory has declined during the preceding years and the philosophy needs to change for allocations of memory. There should be less disk swapping, more dedicated memory, more processed data in dedicated memory and more Real Time operations using dedicated memory.
The Von Naumann architecture, still currently in use, was for a single computer with limited memory. Software design personnel still use this architecture in all of their designs. Design problems are effected by this architecture and primarily due to the computer implementations by the computer manufacturers in order to use existing Software. The design problems are normally dealt with by an Ad Hoc Group (from the SEI of Carnegie Mellon University reference data source) and the individual problems are treated as separate entities. This is a case-by-case basis versus a standards basis. The design must mitigate a large number of problems by eliminating their causes.
System Configurations are normally dependent on the platform and its Operating system. The external interfaces are normally Commercial-off-the-shelf (COTS) or custom design. The system throughput is normally limited by the disk data rates or the internal bus structure. These two factors must be independent of the system throughput. The system should not be limited by External IO rates, Disk Data rates or system bus rates. Internal system interfaces and/or protocols are also factors which can complicate or limit throughput or data input rates. These interfaces must also be independent and accomplished in the simplest fashion on known data types and in the largest feasible data blocks. System Operations are normally planned by the Data base administrator or his System Guru equivalent. The repeatability from one system to another may be similar but normally does not follow published procedures that were initiated during systems implementation and testing but are a result of prior lessons learned. System procedures for System Configuration must be available from the prototyping system testing, must be standardized, and must be used for all future systems.
The majority of real-time CPU's do not have facilities for a Knowledgebase (KB), a data archive facility, a Relational data base with its real-time memory, Displays, or User Graphic user interface interfaces. The components for these facilities need to be added and integrated with the system.